\begin{figure}[H]
\centering \epsfig{file=ProofGenotypeGenePoolDiag1.eps, width=150mm,
height=130mm} \caption{Overview of the relationship between species,
alleles and genotypes}\label{overviewdgabgps}
\end{figure}
\noindent
Figure \ref{overviewdgabgps} provides a diagram overview of \ABGP{} (ABGP). In ABGP, genotypes are aggregates of anonymous computational building blocks called {\em alleles} and of types.  Each allele contains a typed \SF{} term. The type of the term enclosed by the allele specifies the location of a genotype's structure where it may be used as a gene. The type is called {\em gene} and each gene has several alleles. Genotypes combine alleles with other alleles using two combination operations, corresponding to the operations of
functional and type application introduced in \ref{termFormalDef}.
Alleles are compact atomic computational blocks. The type partially specifies what the program (abstractly) does. It is also an
instruction as to where its alleles may be inserted into a genotype. Alleles are closed and can't be opened.
They can only be used or not. The type of the set of alleles completely determines all the possible
pluggings it allows without crashing. One can always substitute the
allele of a given gene with another allele of the same gene in a genotype
to produce a different, but valid genotype.
\newline
\newline
\noindent
Each genotype follows a pattern in the way in which it combines genes. This pattern is specified by the {\em species} to
which the genotype belongs. A species is a proof and a genotype belongs to a species when the typing structure of its gene arrangement is Curry-Howard isomorphic to it.


\MySection{Notation and Programming Syntax}
\subsection{Presentation of Algorithms and Pseudo-Code}
\begin{Program}
\begin{verbatim}
match a with
   | b --> block1
   | c when predicate --> block2
   | _ --> block3
\end{verbatim}
\caption{The $match$ syntactic structure}\label{matchExample}
\end{Program}
\noindent
When we present the algorithms, we use the ``match" syntax (reflected from our Objective Caml implementation). For example, in program \ref{matchExample}, $block1$ is to be executed if $a$ matches $b$ (on a structural level), while $block2$ should be executed when $a$ matches $c$ and $predicate$ evaluates to true. The last block, $block3$ is executed if none of the cases above it have been matched (\_ stands for anything). Order matters, so while there may be several matches to one argument, it is the first match that is executed.
\newline
\newline
\noindent
 We also use some common data structures when we present pseudo-code. We write $a : (B,  C)\ \mathit{Hashtbl}$  to indicate that $a$ is a hash table in which objects of type $B$ index objects of type $C$.  We write $A\ \mathit{list}$ to denote the type of a list of objects of type $A$, and $(A * B)$ to denote the type obtained from a pair of objects of type $A$ and $B$ respectively.
\subsection{Output/Input from Implementation as Examples}
\noindent
We often use text input or output directly from the implementation that we constructed as examples. When we do this,
we use an ascii text format for representing expressions that often contain greek letters and other symbols.
Our implementation's lexer reads:
\begin{enumerate}
\item `\verb|Lam|' as $\Lambda$
\item `\verb|lam|' as $\lambda$
\item `\verb|TT|' as $\Pi$
\item `\verb|->|' as $\rightarrow$
\end{enumerate}


